In business, engineering, government, and many other fields, the need to obtain input from a number of different people is important to ensure that the optimal solution is possible. Thus, to facilitate this interaction between a number of different parties, collaborative modeling software is available. Collaborative modeling software may be configured to permit members of a collaborative community to create and edit various models. These models may include, for example, a set of properties, either concrete or abstract which may describe various objects or additional properties. Models may also describe relationships between objects within the models.
Collaborative modeling software permits a number of individuals to have input on how a model is developed. Many things may constitute a model. By way of example, physical systems may be modeled, machinery may be modeled, atomic or sub-atomic physics may be modeled, business plans may be modeled, societal dynamics may be modeled, and consumer groups may be modeled. The possibilities are endless for the number of model variations and systems that may be modeled. Modeling may include any form of association of data or values with objects that are to be modeled. Models may also include the relationship(s) of one object within a model to another object within the model.
Many people in business need input from their colleagues when undertaking a project. And in many cases projects require or benefit from the collective creation of a “model” of some system of interest. Thus, a more robust and potentially better work product may be produced, and people of various areas of expertise may be permitted to collaborate and combine their talents to produce a final work product. Models may be particularly valuable when the workgroup or community is engaged in a distributed collaborative process. Models may permit these members of the workgroup community to form an explicit basis for collective understanding, progress, and project success. Collaborative systems may be generically grouped into two basic forms: standard collaborative systems and multi-alternative collaborative systems. We also discuss a third type of system, multi-hypothesis management systems, which are not collaborative, but which bear some superficial resemblances to the invention described herein.
Standard collaborative systems permit a community of participants to interact via the collaborative software. These standard systems are generally not configured to be model-based. Examples of these sorts of systems may include, for example, various collaborative environments that handle the underlying communication and often file management infrastructure, often allowing functions such as chat, file sharing and organization, and sometimes shared creation and annotation of documents, electronic sketches, and the like. These systems, however, assume—implicitly, if not explicitly—that differences of opinion must be worked out outside of the collaborative framework. Thus, these standard collaborative systems do not include features supporting the management and resolution of a number of differing perspectives. This may be particularly problematic for collaborative modeling systems, in which “statements” tend to be made with precision, which creates a particularly fertile ground for explicit disagreement and conflict. While some of these systems may alert other users to the lack of agreement about a particular aspect of the model, the collaborative systems do not support maintenance of these differing perspectives. Rather one perspective will be adopted over other perspectives, thereby limiting the opportunity for effective collaboration over aspects of the model.
These issues are tied with two of the primary reasons current collaborative systems are problematic. The first reason is that there is no support for the maintenance of perspectives. This issue is referred to as “intention violation” and may be illustrated by a simple example. A first party is modifying values associated with one object within the model. A second party has determined that—from his perspective—the particular object should no longer exist. In this situation, the collaborative software will violate the intentions of one of the parties. If the first party is permitted to maintain the revised values associated with the object, then the second party's intention regarding the deletion of that object will be violated. Likewise, if the second party is permitted to delete the object, then the intentions of the first party will be violated. Current collaborative systems do not provide adequate protocols for maintaining multiple perspectives and permitting the lack of agreement to be worked out collaboratively.
The second reason that these systems are problematic pertains primarily to peer-to-peer (P2P) asynchronous systems. This is the problem referred to as “indeterminacy.” Like intention violation, the indeterminacy problem may best be described by way of example. Assume that a first party (“Ann”) and a second party (“Bill”) are collaborating—not on a model, but on developing and editing some text. (We use text in this example for simplicity. The problem of indeterminacy will be present, however, any time people are collaborating with separate individual copies of anything where all copies are updated by any mechanism that involves passing around and applying all the transactions representing the changes and updates everyone is making to “their” local copy of the thing, as is described below. This will be the case for text or a model or a diagram or for any other thing on which people are collaborating.) Ann and Bill are able to work on their own copies of the text, and may share (sending and receiving) updates and edits (more formally, transactions applied to the text) to keep their individual copies up-to-date with each other. Let's say, though, that Ann goes offline and is therefore neither sending updates to nor receiving updates from Bill. When Ann comes back online, she and Bill both receive each other's updates, which must be processed in the same order on both copies of the model. To see why this is a requirement, say that while offline Ann performs a search and replace to change all instances of “ACME” to “ACME, Inc.” And while Ann is offline Bill adds a sentence containing the text “ACME.” When Ann comes back online the respective updates will be shared, but if Bill's updates are processed against Ann's copy of the text as and when received, Ann's and Bill's copies of the text will not be consistent (identical): Ann has already done the search and replace, so Bill's update will appear in her copy of the text as “ACME.” In Bill's copy, however, he has already added “ACME,” So when he receives Ann's search and replace transaction for processing against his copy of the text, the instance of “ACME” that he added will be changed to “ACME, Inc.” Therefore some mechanism must be in place to ensure that both updates are processed in the same order for both copies of the text. Now say that a third party (“Cathy”) is collaborating as well. Now updates must be passed around amongst the three collaborators. The same issue as above still applies, but it is now, potentially, even more complex, particularly if the collaborators are going online and offline in various overlapping and non-overlapping patterns. Put another way, all collaborators should be able to process all transactions in the same order as all other collaborators, when they are received, regardless of who was offline (and potentially making changes) and when they were offline. This may be an extremely demanding requirement, but with out some such mechanism for deterministically resolving and processing received updates, each copy of the model could be said to be “indeterminate” as long as someone is offline and potentially queuing up changes that will later be sent out to the others.
Collaborative systems that utilize the multi-alternative approach suffer from a number of deficiencies as well. A collaborative system using the multi-alternative approach permits others to work on a model, but assumes that there is one central model. One individual will have control over the model and thus alternative views may be compared to the central model and may be adjusted by the controller of the central model. This may prohibit others within the collaborating community from developing the model simultaneously. Furthermore, while intentions may be preserved for a short while, they are not preserved indefinitely, and the controller may determine to remove or violate the intentions of one or more of the collaborators. Examples of this type of system include, for example, software, such as, software version control systems that allow “branching and merging” of the versions of a product (typically a text-based document such as software source code or general documents), albeit under the central control of a facilitator or controller.
The final type of contemporary system we describe are a multiple hypothetical management systems. This type of a system may allow the input and storage of multiple values associated with a particular object. These values are hypothetical, and they are then input into an algorithm, which will test the particular hypothesis. This approach allows the expression of alternative values for various aspects of a model. It is certainly possible to apply this approach in a collaborative setting, with the collaborating individuals supplying the alternative values. However, models will ideally contain values and relationships, and this approach allows only the expression of multiple values for a given object in a model. Furthermore, these hypothetical management systems are many times not even used in collaborative environments because the work utilized is typically from one source and an algorithm will test the alternatives provided by a some other component of the system. Examples of these types of systems may come in the form of engineering-related software. Examples of such software may include, for example, multi-hypothesis tracking systems and the Viterbi decoding algorithm used in various signal processing and estimation applications.
As can be seen from the foregoing, contemporary systems do not provide adequate features to enable effective collaboration within a collaboration system. Particularly, many systems fail to preserve the intentions of the collaborators within the collaborating community. Furthermore, some of the systems are controlled by a central controller and will allow only that person to determine which perspectives to adopt. Therefore, what is needed is a system and method for enabling multi-perspective collaborative modeling in which intentions are preserved indefinitely. Furthermore, what is needed is a system and method for multi-perspective collaborative modeling that will establish ownership over a particular perspective within the model, and will facilitate social interaction among collaborators to reach agreement—or, potentially, to preserve meaningful disagreement—over particular aspects of the model.